• pnpm-lock.yaml: Language not supported

packages/runtime/src/client/client-impl.ts (1)

369-372: Bug: post-processing uses the original args instead of the possibly overridden _args

Plugins can override args by wrapping proceed. Using the outer args here ignores those overrides and can lead to incorrect result processing (e.g., select/include).

Apply this diff:

-                if (r && postProcess) {
-                    result = resultProcessor.processResult(r, model, args);
-                } else {
+                if (r && postProcess) {
+                    result = resultProcessor.processResult(r, model, _args as any);
+                } else {

packages/runtime/src/client/helpers/schema-db-pusher.ts (2)

191-194: Handle arrays and provider differences for custom types

The early return maps every custom type to plain jsonb, which:

• bypasses the array handling below (Lines 210–216), so CustomType[] becomes jsonb instead of jsonb[] (PostgreSQL),
• forces jsonb on non-PostgreSQL providers, which can be an invalid or undesirable column type.

Consider adding array handling and gating by provider:

-        if (this.isCustomType(fieldDef.type)) {
-            return 'jsonb';
-        }
+        if (this.isCustomType(fieldDef.type)) {
+            if (this.schema.provider.type === 'postgresql') {
+                return fieldDef.array ? sql.raw('jsonb[]') : 'jsonb';
+            }
+            // Non-Postgres fallback for custom types. Consider aligning with how `Json` is handled cross-provider.
+            return 'text';
+        }

Notes:

• If you intend custom types to behave like built-in Json everywhere, mirror whatever cross-provider strategy you want for Json (today it returns jsonb unconditionally). If keeping jsonb universally is intentional, at least fix the array case: return fieldDef.array ? sql.raw('jsonb[]') : 'jsonb';
• To avoid accidental shadowing of built-ins by custom types named like Int, String, etc., ensure isCustomType excludes known built-ins or move custom-type resolution after built-in detection.

---

218-221: Make custom-type detection O(1) and more robust

Object.values(...).some(...) is O(n) per call and repeats for every field. If typeDefs is keyed by type name (likely), you can simplify and speed this up. Also be explicit about nullability.

-    private isCustomType(type: string) {
-        return this.schema.typeDefs && Object.values(this.schema.typeDefs).some((def) => def.name === type);
-    }
+    private isCustomType(type: string) {
+        const defs = this.schema.typeDefs;
+        // If `typeDefs` is keyed by name, prefer O(1) lookup:
+        return !!defs && Object.prototype.hasOwnProperty.call(defs, type);
+    }

If typeDefs is NOT keyed by name, keep current semantics but consider precomputing a Set once for O(1) lookups:

// Outside the selected lines: example approach
private readonly customTypeNames = new Set<string>(
    Object.values(this.schema.typeDefs ?? {}).map((d) => d.name),
);

private isCustomType(type: string) {
    return this.customTypeNames.has(type);
}

Optionally also add a guard to exclude known built-ins to prevent shadowing.

packages/zod/src/index.ts (1)

10-10: Optional: align the SelectSchema type with strictness

SelectSchema currently aliases ZodObject<...> without specifying the unknown-keys mode (defaults to 'strip'), while the runtime schema here is strict. Consider updating the type to reflect strictness for better type fidelity.

If acceptable, adjust packages/zod/src/types.ts:

// before
export type SelectSchema<Schema extends SchemaDef, Model extends GetModels<Schema>> = ZodObject<{
    [Key in ScalarFields<Schema, Model>]: MapScalarType<Schema, Model, Key>;
}>;

// after (note: second generic param 'strict')
export type SelectSchema<Schema extends SchemaDef, Model extends GetModels<Schema>> = ZodObject<{
    [Key in ScalarFields<Schema, Model>]: MapScalarType<Schema, Model, Key>;
}, 'strict'>;

pnpm-workspace.yaml (1)

8-8: Keep Prisma CLI and Client in lockstep via catalog

Recommend adding '@prisma/client' to the catalog with the same range as 'prisma' to avoid drift across packages and samples. This prevents subtle mismatches between generator and client.

Apply this diff:

 catalog:
     kysely: ^0.27.6
     zod: ^4.0.0
     prisma: ^6.14.0
+    '@prisma/client': ^6.14.0
     langium: 3.5.0
     langium-cli: 3.5.0
     ts-pattern: ^5.7.1
     typescript: ^5.0.0
     '@types/node': ^20.17.24
     tmp: ^0.2.3
     '@types/tmp': ^0.2.6

packages/language/src/validators/datamodel-validator.ts (1)

443-447: Tiny readability refactor: capture the base model ref once

To avoid repeating property access and non-null assertions, grab a local baseModelRef after the invariant and reuse it.

Apply this diff:

-        invariant(model.baseModel.ref, 'baseModel must be resolved');
-
-        // check if the base model is a delegate model
-        if (!isDelegateModel(model.baseModel.ref!)) {
+        const baseModelRef = model.baseModel.ref;
+        invariant(baseModelRef, 'baseModel must be resolved');
+
+        // check if the base model is a delegate model
+        if (!isDelegateModel(baseModelRef)) {
             accept('error', `Model ${model.baseModel.$refText} cannot be extended because it's not a delegate model`, {
                 node: model,
                 property: 'baseModel',
             });
             return;
         }

.vscode/launch.json (1)

13-15: Relying on CWD for schema discovery matches the new plugin-driven flow

Switching to args: ["generate"] with cwd pointing at the sample app’s zenstack folder is consistent with the updated CLI behavior.

Optionally add verbose logging to ease debugging:

-            "args": ["generate"],
+            "args": ["generate", "--verbose"],

TODO.md (5)

12-15: Fix markdown list indentation (MD007) for nested bullets under "CLI".

Current indentation uses 4 and 8 spaces; markdownlint expects 2 and 4 for 2nd/3rd levels. Adjust as below.

-    - [x] plugin mechanism
-    - [x] built-in plugins
-        - [x] ts
-        - [x] prisma
+  - [x] plugin mechanism
+  - [x] built-in plugins
+    - [x] ts
+    - [x] prisma

---

17-19: Normalize indentation for "ZModel" sub-items (MD007).

Use 2 spaces for the second-level list items under ZModel.

-    - [x] Import
+  - [x] Import
-    - [ ] Datasource provider-scoped attributes
+  - [ ] Datasource provider-scoped attributes

---

88-89: Indentation of "Migrate to tsdown" under ORM/Misc is too deep.

Expected 3rd-level indent (4 spaces) per markdownlint; reduce by 4 spaces.

-        - [ ] Migrate to tsdown
+    - [ ] Migrate to tsdown

Note: Line 89 starts the next section; ensure its indentation is consistent with its parent as well.

---

91-91: Indentation for "Post-mutation hooks..." under "Plugin" should be 2 spaces.

-    - [x] Post-mutation hooks should be called after transaction is committed
+  - [x] Post-mutation hooks should be called after transaction is committed

---

109-109: Indentation for "MySQL" under "Databases" (MD007).

Make it a second-level bullet (2 spaces).

-    - [ ] MySQL
+  - [ ] MySQL

packages/runtime/src/client/crud-types.ts (1)

633-644: Provider-gated distinct in FindArgs is correct; consider aligning validator behavior.

Typing only exposes distinct for PostgreSQL via ProviderSupportsDistinct, which matches dialect capabilities. However, the runtime validator currently always accepts distinct (see validator.ts Line 212-218). Consider gating in the validator too for consistency and earlier feedback to users.

If helpful, I can patch validator.ts to only allow distinct when schema.provider.type === 'postgresql'.

packages/runtime/src/client/crud/validator.ts (2)

212-218: Gate distinct by provider for consistency with types and dialects.

Types only allow distinct for PostgreSQL, but the validator accepts it unconditionally. Aligning validator prevents confusing "accepted but ignored" args on providers that don't support it.

-            fields['distinct'] = this.makeDistinctSchema(model).optional();
+            if (this.schema.provider.type === 'postgresql') {
+                fields['distinct'] = this.makeDistinctSchema(model).optional();
+            }

---

630-656: Gate relation distinct for to-many includes by provider as well.

Same rationale as above: only PostgreSQL supports DISTINCT ON(field). Keep runtime validation aligned with type-level gating.

-            ...(fieldDef.array
-                ? {
-                      // to-many relations can be ordered, skipped, taken, and cursor-located
-                      orderBy: z.lazy(() => this.makeOrderBySchema(fieldDef.type, true, false)).optional(),
-                      skip: this.makeSkipSchema().optional(),
-                      take: this.makeTakeSchema().optional(),
-                      cursor: this.makeCursorSchema(fieldDef.type).optional(),
-                      distinct: this.makeDistinctSchema(fieldDef.type).optional(),
-                  }
-                : {}),
+            ...(fieldDef.array
+                ? {
+                      // to-many relations can be ordered, skipped, taken, and cursor-located
+                      orderBy: z.lazy(() => this.makeOrderBySchema(fieldDef.type, true, false)).optional(),
+                      skip: this.makeSkipSchema().optional(),
+                      take: this.makeTakeSchema().optional(),
+                      cursor: this.makeCursorSchema(fieldDef.type).optional(),
+                      ...(this.schema.provider.type === 'postgresql'
+                          ? { distinct: this.makeDistinctSchema(fieldDef.type).optional() }
+                          : {}),
+                  }
+                : {}),

packages/runtime/test/scripts/generate.ts (1)

24-29: Surface load warnings and improve error readability

Minor DX improvement: print warnings from loadDocument and format errors line-by-line. This helps when schema validations fail during CI.

Apply:

-    const result = await loadDocument(schemaPath, pluginModelFiles);
-    if (!result.success) {
-        throw new Error(`Failed to load schema from ${schemaPath}: ${result.errors}`);
-    }
-    await generator.generate(result.model, outputDir);
+    const result = await loadDocument(schemaPath, pluginModelFiles);
+    if (result.warnings?.length) {
+        console.warn(`Warnings while loading schema from ${schemaPath}:\n${result.warnings.join('\n')}`);
+    }
+    if (!result.success) {
+        throw new Error(`Failed to load schema from ${schemaPath}:\n${result.errors.join('\n')}`);
+    }
+    await generator.generate(result.model, outputDir);

packages/cli/src/plugins/prisma.ts (2)

9-17: Always ensure the output directory exists (even for the default path)

Right now mkdirSync runs only when pluginOptions.output is provided. If defaultOutputPath hasn’t been created by the caller, writeFileSync will fail. Make directory creation unconditional.

Apply this diff:

         let outDir = defaultOutputPath;
         if (typeof pluginOptions['output'] === 'string') {
             outDir = path.resolve(defaultOutputPath, pluginOptions['output']);
-            if (!fs.existsSync(outDir)) {
-                fs.mkdirSync(outDir, { recursive: true });
-            }
         }
+        if (!fs.existsSync(outDir)) {
+            fs.mkdirSync(outDir, { recursive: true });
+        }
         const prismaSchema = await new PrismaSchemaGenerator(model).generate();
         fs.writeFileSync(path.join(outDir, 'schema.prisma'), prismaSchema);

---

10-11: Optional: Disallow absolute output paths to keep generation confined under the default output root

If you want to prevent plugins from writing outside defaultOutputPath, guard against absolute output values.

Example:

-        if (typeof pluginOptions['output'] === 'string') {
+        if (typeof pluginOptions['output'] === 'string') {
+            if (path.isAbsolute(pluginOptions['output'])) {
+                throw new Error(`'output' must be a relative path`);
+            }
             outDir = path.resolve(defaultOutputPath, pluginOptions['output']);

packages/cli/test/plugins/prisma-plugin.test.ts (1)

17-30: Optional: Add a quick content sanity check

To catch accidental empty writes, consider a minimal file-size or non-empty content check in addition to existsSync. This isn’t critical but can surface regressions earlier.

Example:

const tsPath = path.join(workDir, 'generated-schema/schema.ts');
expect(fs.existsSync(tsPath)).toBe(true);
expect(fs.readFileSync(tsPath, 'utf8').length).toBeGreaterThan(0);

packages/cli/src/plugins/typescript.ts (2)

10-18: Unconditionally ensure the output directory exists

Similar to the Prisma plugin, mkdirSync currently happens only when pluginOptions.output is set. TsSchemaGenerator will usually create directories, but making it explicit here improves robustness and consistency.

Apply this diff:

         let outDir = defaultOutputPath;
         if (typeof pluginOptions['output'] === 'string') {
             outDir = path.resolve(defaultOutputPath, pluginOptions['output']);
-            if (!fs.existsSync(outDir)) {
-                fs.mkdirSync(outDir, { recursive: true });
-            }
         }
+        if (!fs.existsSync(outDir)) {
+            fs.mkdirSync(outDir, { recursive: true });
+        }
         await new TsSchemaGenerator().generate(model, outDir);

---

9-16: Optional: Avoid duplication by extracting a shared helper for output resolution

Both plugins share identical outDir resolution/creation logic. Consider a small helper under packages/cli/src/plugins/_utils.ts to reduce drift.

Example helper (new file: packages/cli/src/plugins/_utils.ts):

import fs from 'node:fs';
import path from 'node:path';

export function resolveOutDir(defaultOutputPath: string, pluginOptions: Record<string, unknown>) {
    let outDir = defaultOutputPath;
    const output = pluginOptions['output'];
    if (typeof output === 'string') {
        if (path.isAbsolute(output)) {
            throw new Error(`'output' must be a relative path`);
        }
        outDir = path.resolve(defaultOutputPath, output);
    }
    fs.mkdirSync(outDir, { recursive: true });
    return outDir;
}

Then in each plugin:

import { resolveOutDir } from './_utils';
const outDir = resolveOutDir(defaultOutputPath, pluginOptions);

packages/testtools/src/schema.ts (2)

45-48: Improve error message formatting and include all diagnostics

When loadDocument fails, result.errors is an array; interpolating it directly results in a comma-joined string. Joining with newlines improves readability.

Also consider surfacing result.warnings (if any) to aid debugging.

Apply this diff for clearer error output:

-    if (!result.success) {
-        throw new Error(`Failed to load schema from ${zmodelPath}: ${result.errors}`);
-    }
+    if (!result.success) {
+        throw new Error(`Failed to load schema from ${zmodelPath}:\n${result.errors.join('\n')}`);
+    }

Optionally, log warnings after a successful load:

• if (result.warnings.length) console.warn(Schema warnings:\n${result.warnings.join('\n')});

---

85-87: Mirror the improved error formatting here as well

Same suggestion as above for better readability and diagnostics when loading from a schema path fails.

Apply this diff:

-    if (!result.success) {
-        throw new Error(`Failed to load schema from ${schemaPath}: ${result.errors}`);
-    }
+    if (!result.success) {
+        throw new Error(`Failed to load schema from ${schemaPath}:\n${result.errors.join('\n')}`);
+    }

packages/runtime/src/client/crud/operations/find.ts (1)

6-24: Guard against unsupported operations at runtime

The handler is specific to find operations but the signature accepts any CoreCrudOperation. Adding a lightweight runtime guard prevents accidental dispatch (and surfaces clearer errors).

Apply this diff to add a defensive check:

 export class FindOperationHandler<Schema extends SchemaDef> extends BaseOperationHandler<Schema> {
-    async handle(operation: CoreCrudOperation, args: unknown, validateArgs = true): Promise<unknown> {
+    async handle(operation: CoreCrudOperation, args: unknown, validateArgs = true): Promise<unknown> {
+        if (operation !== 'findMany' && operation !== 'findUnique' && operation !== 'findFirst') {
+            throw new Error(`FindOperationHandler received unsupported operation: ${operation}`);
+        }
         // normalize args to strip `undefined` fields
         const normalizedArgs = this.normalizeArgs(args);

packages/cli/test/plugins/custom-plugin.test.ts (1)

1-50: End-to-end plugin generation test reads well; add a quick content assertion

The test exercises the custom plugin path correctly (TS compilation, CLI invocation, output path resolution). Consider also asserting the file content to catch false positives where a file exists but is empty or wrong.

Apply this diff:

         runCli('generate', workDir);
         expect(fs.existsSync(path.join(workDir, 'custom-output/foo.txt'))).toBe(true);
+        expect(fs.readFileSync(path.join(workDir, 'custom-output/foo.txt'), 'utf8')).toBe('from my plugin');

packages/runtime/test/client-api/find.test.ts (1)

244-249: Distinct behavior tests: good coverage, minor type nit

• Creating duplicate post titles for dedup validation is spot-on.
• Gating SQLite with an explicit rejection check is appropriate given provider capabilities.
• Include/select combinations are exercised well.

Nit: using as any for distinct is understandable for cross-backend typing, but consider narrowing types in tests to avoid any where possible.

Also applies to: 264-271, 279-305

packages/runtime/src/client/crud/dialects/base.ts (2)

62-108: Centralized where/skip-take/orderBy/distinct/cursor composition is a good consolidation; consider default order when using cursor

This method greatly improves consistency. One functional suggestion: when a cursor is present and no explicit orderBy is provided, applying the default order ensures deterministic paging.

Apply this diff to enable default ordering when a cursor is used:

         result = this.buildOrderBy(
             result,
             model,
             model,
             args.orderBy,
-            skip !== undefined || take !== undefined,
+            skip !== undefined || take !== undefined || args.cursor !== undefined,
             negateOrderBy,
         );

Optional: For DISTINCT ON determinism, consider prepending distinct fields to the ORDER BY when supported (leftmost), or at least documenting the behavior when orderBy is omitted.

---

169-208: Cursor filter: make subquery scalar and ignore non-scalar orderings

Two robustness tweaks:

• Ensure the subquery used for comparisons returns a single row (defensive, even if cursor is unique).
• Filter orderBy entries to scalar sorts only ('asc' | 'desc'), falling back to the default if none remain. This prevents accidental inclusion of relation/aggregate sorts that the lexical cursor comparison can’t handle.

Apply this diff:

-        const _orderBy = orderBy ?? makeDefaultOrderBy(this.schema, model);
-
-        const orderByItems = ensureArray(_orderBy).flatMap((obj) => Object.entries<SortOrder>(obj));
+        const _orderBy = orderBy ?? makeDefaultOrderBy(this.schema, model);
+
+        let orderByItems = ensureArray(_orderBy)
+            .flatMap((obj) => Object.entries(obj))
+            .filter(([, v]) => v === 'asc' || v === 'desc') as [string, SortOrder][];
+        if (orderByItems.length === 0) {
+            orderByItems = ensureArray(makeDefaultOrderBy(this.schema, model))
+                .flatMap((obj) => Object.entries(obj)) as [string, SortOrder][];
+        }
@@
-                        eb.selectFrom(model).select(`${model}.${field}`).where(cursorFilter),
+                        eb.selectFrom(model).select(`${model}.${field}`).where(cursorFilter).limit(1),

Note: If you intend to support cursor with aggregate/relation orderings later, this area will need a different strategy (e.g., projecting computed order keys in a CTE and comparing tuples).

packages/cli/src/actions/generate.ts (5)

78-81: Improve dynamic import error message

Interpolating the error object yields “[object Object]”. Prefer the message for clarity.

Apply this diff:

-            } catch (error) {
-                throw new CliError(`Failed to load plugin ${provider}: ${error}`);
-            }
+            } catch (error) {
+                throw new CliError(
+                    `Failed to load plugin ${provider}: ${
+                        error instanceof Error ? error.message : String(error)
+                    }`,
+                );
+            }

---

95-99: Prefer CLI-friendly error for missing generate()

Use CliError so the top-level CLI can render a consistent, user-friendly message.

Apply this diff:

-        invariant(
-            typeof cliPlugin.generate === 'function',
-            `Plugin ${cliPlugin.name} does not have a generate function`,
-        );
+        if (typeof cliPlugin.generate !== 'function') {
+            throw new CliError(`Plugin ${cliPlugin.name} does not have a generate function`);
+        }

---

87-92: Nit: reverse() on a single-element array is redundant

defaultPlugins contains one element; reverse() is a no-op. Consider removing for clarity.

No code change required; optional cleanup:

-    const defaultPlugins = [corePlugins['typescript']].reverse();
+    const defaultPlugins = [corePlugins['typescript']];

---

101-109: Consider honoring --silent for spinners and logs

Even when options.silent is true, ora spinners (and console.warn in getPluginOptions) still emit output. Consider threading a silent flag into runPlugins to disable spinners and warnings.

If you choose to implement, minimal shape:

• Add a silent param to runPlugins and gate spinner creation with it.
• Gate console.warns in option parsing behind the same flag (or route through a logger).

Happy to provide a concrete patch if you want to wire silent through.

---

29-33: Add tests to verify plugin failures abort the generate command

There’s currently no test ensuring that a plugin error prevents the generate command from printing a success message. Without this, a regression could allow “Generation completed successfully” to appear even when a plugin fails. Please add a test (e.g. packages/cli/test/generate.test.ts) that:

• Installs or mocks a plugin whose generate hook throws an error (or omits the generate function).
• Invokes the CLI via runCli('generate', workDir) (or equivalent).
• Asserts that it rejects or exits with a non-zero code, not logging the success message.

This will guard against silent failures in plugin execution.

Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro

💡 Knowledge Base configuration:

• MCP integration is disabled by default for public repositories
• Jira integration is disabled by default for public repositories
• Linear integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

Learnt from: CR
PR: zenstackhq/zenstack-v3#0
File: CLAUDE.md:0-0
Timestamp: 2025-08-04T08:43:33.161Z
Learning: Database migrations still use Prisma CLI under the hood

Learnt from: CR
PR: zenstackhq/zenstack-v3#0
File: CLAUDE.md:0-0
Timestamp: 2025-08-04T08:43:33.161Z
Learning: `zenstack generate` compiles ZModel to TypeScript schema (`schema.ts`)

Learnt from: CR
PR: zenstackhq/zenstack-v3#0
File: CLAUDE.md:0-0
Timestamp: 2025-08-04T08:43:33.161Z
Learning: No runtime dependency on prisma/client

Learnt from: CR
PR: zenstackhq/zenstack-v3#0
File: CLAUDE.md:0-0
Timestamp: 2025-08-04T08:43:33.161Z
Learning: ZModel schema (`schema.zmodel`) defines database structure and policies

Learnt from: CR
PR: zenstackhq/zenstack-v3#0
File: CLAUDE.md:0-0
Timestamp: 2025-08-04T08:43:33.161Z
Learning: Schema-first approach with ZModel DSL extension of Prisma schema language

Learnt from: CR
PR: zenstackhq/zenstack-v3#0
File: CLAUDE.md:0-0
Timestamp: 2025-08-04T08:43:33.161Z
Learning: Applies to **/schema.zmodel : Always run `zenstack generate` after modifying ZModel schemas